Asdf-Support#708
Conversation
braingram
left a comment
There was a problem hiding this comment.
Thanks for sharing your work. It looks like a great start! I left a bunch of comments. I did not look over the ndcube.py changes.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
There was a problem hiding this comment.
I'm a bit confused. Several of the suggestions in my previous comments were marked as resolved with responses that gave me the impression they were "ok" yet the changes were not made. I was going through updating comments but stopped when I realized this PR might not be up-to-date.
Are there changes not committed that have the previous suggestions? If not, is there a reason these suggestions were dismissed?
EDIT: I'm not sure what's up with github but me posting this comment caused the PR to update for me :-/ I'm now seeing the changes made in cd31d95 which I did not previously see.
braingram
left a comment
There was a problem hiding this comment.
Now that I'm looking at the newest code 🤦
Just a few comments/questions and one request.
Would you add asdf to the dependencies and set a version that makes the oldestdeps job happy?
Sure, I am on it. |
braingram
left a comment
There was a problem hiding this comment.
Looks good to me. Thanks!
Cadair
left a comment
There was a problem hiding this comment.
This PR looks amazing @ViciousEagle03 thanks for all your work on it. I have a few small-ish comments and then I think we can merge it.
| extra_coords._mapping = node.get("mapping") | ||
| extra_coords._lookup_tables = node.get("lookup_tables", []) | ||
| extra_coords._dropped_tables = node.get("dropped_tables") | ||
| extra_coords._ndcube = node.get("ndcube") |
There was a problem hiding this comment.
@braingram @ViciousEagle03 is asdf smart enough to handle this circular reference and not save out the ndcube object twice? i.e. I save an NDCube which has an ExtraCoords which references the same NDCube?
There was a problem hiding this comment.
Theoretically yes but I believe the converter will need to be updated.
https://asdf.readthedocs.io/en/latest/asdf/extending/converters.html#reference-cycles
That seems like a good test case.
There was a problem hiding this comment.
@braingram, for the current implementation I believe it is still not storing the NDCube object twice, right?
And also in the current from_yaml_tree method, it doesn't have yield but it can still deserialize the extra_coords object, that is, when the extra_coords converter is called the extra_coords.ndcube shows _PendingValue and when it gets picked up in the NDCube converter and the ndcube.extra_coords is initialized the reference to the ndcube is properly mapped in the ndcube.extra_coords._ndcube.
We can see the deserialized NDCube object and the NDCube reference address for the ExtraCoords associated is the same for the below.
(Pdb) ndcube.extra_coords._ndcube
<ndcube.ndcube.NDCube object at 0x7c84fe60c2d0>
NDCube
------
Shape: (10, 10)
Physical Types of Axes: [('em.energy', 'time', 'pos.eq.ra', 'pos.eq.dec'), ('time', 'custom:CUSTOM')]
Unit: None
Data Type: float64
(Pdb) ndcube
<ndcube.ndcube.NDCube object at 0x7c84fe60c2d0>
NDCube
------
Shape: (10, 10)
Physical Types of Axes: [('em.energy', 'time', 'pos.eq.ra', 'pos.eq.dec'), ('time', 'custom:CUSTOM')]
Unit: None
Data Type: float64
(Pdb)
There was a problem hiding this comment.
Thanks for testing this out. This looks to be working because __set__ overwrites _ndcube when _extra_coords is assigned:
Line 321 in 09a83f1
I am not sure what's going on with
__set__. @Cadair is there ever an instance where:
- the
extra_coordsattached to aNDCubewill reference a differentNDCube? extra_coordswill exist without aNDCube?
There was a problem hiding this comment.
the
extra_coordsattached to aNDCubewill reference a differentNDCube?
No, that should be explicitly prohibited by the descriptor.
extra_coordswill exist without aNDCube?
I think this might be possible yes.
There was a problem hiding this comment.
extra_coordswill exist without aNDCube?I think this might be possible yes.
Is there a minimal example that would show this? Perhaps it can be used for a test case for the converter.
There was a problem hiding this comment.
I think you can just instantiate one standalone and then add some coordinates to it with the same API as you can if it's attached to the cube.
|
One other minor request. Would you rename the |
|
Apologies for the delay, @nabobalis would you mind taking a look? As I mentioned earlier, the |
It is creating a warning which is failing the CI:
I would just ignore the warning being created by adding it to the pytest.ini list. |
Hey @nabobalis, thanks for the help. Even after adding the |
Yeah that makes sense. If there is no functional way to do pixel_shape serialization until this version of gwcs, skipping them for versions older than 0.20 is to me the best way. |
Cadair
left a comment
There was a problem hiding this comment.
This looks great to me. All my comments are minor.
| extra_coords._mapping = node.get("mapping") | ||
| extra_coords._lookup_tables = node.get("lookup_tables", []) | ||
| extra_coords._dropped_tables = node.get("dropped_tables") | ||
| extra_coords._ndcube = node.get("ndcube") |
There was a problem hiding this comment.
the
extra_coordsattached to aNDCubewill reference a differentNDCube?
No, that should be explicitly prohibited by the descriptor.
extra_coordswill exist without aNDCube?
I think this might be possible yes.
This PR adds ASDF support for ndcube objects.
GitHub Project Board Link
This Pull Request is currently a
Work In Progressand will be continuously updated as we expand support for serializingndcubeobjects to ASDF.